System design involves creating, developing, and refining electronic designs such as channels, memory, and other structures for implementation in electronic devices. The design process may involve several domains (or phases), including a system level design domain/phase, a logic/DSP design domain/phase, a hardware level design domain/phase and a software level design domain/phase.
System design may be done using system level electronic design automation (EDA) tools that allow a designer to model, simulate, and analyze systems. Some system level EDA tools such as Simulink® from MathWorks® allow designers to create, simulate, evaluate, and refine a system design model through standard and custom block libraries. Users may design and simulate algorithms in Simulink® or other simulator tools by entering logic blocks and associated connections using a graphical user interface. The system level design may then be compiled and evaluated in the logic/DSP domain and/or in the hardware design domain. For example, system characteristics such as noise immunity, error recovery, and power consumption may be evaluated using simulation and complex mathematical analysis software. System characteristics may also be evaluated using hardware testing, by downloading the design into a hardware platform and measuring the system characteristics in the hardware. Block libraries such as DSP Builder from Altera® Corporation provide digital signal processing (DSP) development tools that interface between system level EDA tools (for performing design modeling and analysis) and hardware design flow tools (for performing synthesis, placement, and routing).
Current design flows may limit interoperability with existing designs and/or with simulation models. For example, current system level EDA tools and block libraries may provide limited support for converting designs written in hardware description language (HDL) code to a simulation model having a format compatible with the system level EDA tools. This makes it difficult for users to reuse existing designs written in HDL code, and may decrease robustness and efficiency. Some block libraries impose rules on HDL port declarations where certain signals need to be renamed in order for the block libraries to recognize the signals and make the appropriate connections in the simulation model. In addition, many of these block libraries do not allow a user of the system level EDA tool to select how a simulation model of a design written in HDL code should be represented in the system level environment.
Current design flows may make it difficult to connect designs written in HDL code to other components of the system. In some cases, connecting a system level representation of a hardware block to another component may force the designer to create additional interface-specific blocks. For example, to create an interface between an HDL representation of a hardware block and a processor, users may have to manually define an interface block for each signal of the hardware block so that the processor is able to properly supply input data to the hardware block and/or properly read output data from the hardware block. In addition, users may have to create handshaking logic and/or draw logic schematics to enable coordinated execution between the hardware block and the processor. For example, users may need to manually create software drivers for the processor to communicate with the hardware block generated from the HDL representation. In addition to being tedious, time-consuming, and error-prone, this current approach may be incompatible with the simulation model used in the simulator tools. As a result, design flows may not be supported for running simulation vectors directly from the processor into the generated hardware.